home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 495 < prev    next >
Internet Message Format  |  1994-08-27  |  4KB
  1. From: Mark.Baker@mettav.royle.org (Mark Baker)
  2. Date: 26 Jun 94  18:24:10
  3. Message-Id: <UUCP.772743608@mettav>
  4. Subject: Re: A Proposal For Everyone
  5. To: gem-list@world.std.com (gem-list@world.std.com)
  6. Precedence: bulk
  7.  
  8. Evan:
  9.  > OK, how about shift-tab for backtab, and ^tab for cycle windows? or
  10.  > is that bad too?   TAB could stay as cycle object for object based apps
  11.  > and non-text apps.  Shift-tab for reverse cycle (of objects in non-text
  12.  > apps) and shift ^ tab for reverse cycle windows?
  13.  
  14. That makes sense. Should ^tab cycle windows within the current app, or use
  15. wind_get(WF_BOTTOM) as clicking on the title bar would? If the latter, how
  16. would you implement shift ^tab on the Atari?
  17.  
  18.  > Hmm .. I kinda like ^d because its easy (no shift keys) and finding a
  19.  > next isn't really the opposite of finding previous.  If you look at the
  20.  > position of the keys, its really nice.  ^f for find in the middle.  The
  21.  > "next" key (position wise) is ^g for find next.  And teh previous key is ^d
  22.  > for find previous.  That makes ALOT of sense to me, and again its a NeXT
  23.  > standard.  However, ATARI doesn't define find next OR find previous, so
  24.  > they aren't gonna back me up here :-)
  25.  
  26. This makes sense, but find previous is as near the opposite to find next as
  27. you're going to get and shift-ctrl-g leaves ctrl-d free for something else,
  28. perhaps deselect block?
  29.  
  30.  > I'll make the changes the my end for the TAB differences.  And remove ^e.
  31.  
  32. Don't remove ctrl-e, if it's what I think it is then it's very useful.
  33.  
  34. Ken:
  35.  > Sliders MUST be handled in a redraw-as-you-drag (or active-drawing)
  36.  > method in order to provide full functionality.  Any sliders that are
  37.  > designed to display information (such as scaling percentages, etc) should
  38.  > be displayed either within the slider bar, or to the direct right or
  39.  > left of the slider track.  Sliders that take time to draw information
  40.  > based on their position must be ghost-drag type.
  41.  
  42. Obviously active-draw sliders are not something that can be handled by
  43. let-em-fly automatically and require the app. programmer to handle it.
  44. Generally this all makes sense, using a solid button for active-draw and a
  45. ghost button for ones that redraw afterwards.
  46.  
  47.  > Hotkeys must be identified by either an underline, an inverted character,
  48.  
  49. Not particularly to do with the user interface, but a feature I would like to
  50. see in let-em-fly would be a way to stop it assigning hotkeys to particular
  51. objects, eg. items on a scrolling list (since these change as the list is
  52. scrolled) Only assigning hotkeys to BUTTONs, not STRING, TEXT etc, would help.
  53.  
  54.  >      + SHIFT-CTRL  : Insert text from clipboard at its current
  55.  >                      position, then move the counter up one.  Press
  56.  >                      again to get the next previously entered string.
  57.  
  58. Do you mean the clipboard, or the history buffer, or will these be the same?
  59.  
  60.  >    - Delete        : Delete character in front of cursor.
  61.  >      + LSHIFT      : Delete all text to left of cursor.
  62.  >      + RSHIFT      : Delete all text to right of cursor.
  63.  >      + L&RSHIFT    : Delete entire editable field.  (Same as [ESC])
  64.  
  65. I don't like programs differentiating between the shift keys, since they are
  66. marked indentically. How about shift-del for delete line right and shift-bs for
  67. delete line left, as on Everest? Or use ctrl-shift-{del|bs} for these and keep
  68. shift-del for delete line as normal.
  69.  
  70.  > Instead of having the clipboard at a set place (like U:\CLIP or whatever)
  71.  > why not have it set in an environmental variable?  I propose that the
  72.  > following four environmental variables be reserved for clipboard
  73.  > directory locations:
  74.  >
  75.  > CLIPBRD, SCRAPDIR     -- These are standards to GEM
  76.  > TMP, TEMP             -- These are standards to Unix/Linux
  77.  
  78. Surely you can use the AES scrp_xxx functions for this? The environment
  79. variables should also be st, for use by TOS programs, but we're talking GEM
  80. programs here.
  81.  
  82. Ofir:
  83.  >> - Insert        : Toggle insert/overwrite mode (change cursor too.)
  84.  >> + SHIFT       : Bring up a character table to select characters to
  85.  >> input into the editable field.
  86.  >
  87.  > I thought you were going to follow the current propsal Shift+CTRL+Z
  88.  
  89. I prefer shift-insert TBH, but I agree that the existing proposal should be
  90. stuck to.
  91.  
  92.  
  93.  
  94.